寫到這裡，我再度回顧，自己到底會了什麼？更實在地問，我真的會開發了嗎？

如果完全拿掉 AI，我會的程度跟有 AI 之前比，有什麼進步？

在公司上班當 PM 的時候，我的工作是：搞清楚市場與需求，排好開發時間、檢查時間點，以及之後要做測試的人與資源，然後等，把空間留給開發同事。

有關技術選型、實作方法、衝突排解、Code Review、單元測試，我知道的是零。

跟 AI 合作後呢？我多知道一些開發前後必須做的事情，像是規格寫得更細更清楚、申請權限要自己按、每到段落記得備份存檔、安全檢查。

但是回到我說自己知道為零的事情？上班時候，為了留給開發同事更大的空間，作為 PM 我不會亂問一些白痴問題，真的要問多半是跟需求、資源、時程相關。而且也不會沒事亂問打亂人家工作節奏，我會把問題攢起來一次問。

跟 AI 協作的話，不需要考慮給人留空間，發問的成本幾近於零，我有因此多問一些開發端問題嗎？

我請 CC 幫我檢查這幾個 App 開發過程中，AI 問我的問題，以及我問 AI 的問題是哪些類別，又各發生了多少次。

這是 AI 問我的問題：

這是我問 AI 的：

兩張表要分開看，因為算法不一樣。

上面那張是普查：CC 在《這趟》開工到上架那十一天裡問我的問句，全部抓出來去重，共 36 個。下面那張是抽樣：四個對話串我一共發了 912 則，濾掉我貼進去的退件信、錯誤訊息跟研究報告之後剩 753 則，隨機抽 90 則人工讀，其中有內容的 74 則。誤差大概正負十個百分點。

（補一句，我本來想用關鍵字自動分類，結果 69% 掉進「其他」，分類失敗才改成人工讀的。）

它問我的 36 個問題裡，沒有一個是技術選型或架構。我的訊息抽樣 74 則裡，問原理的只有 1 則。

兩邊都沒有在談架構。它不說，我也不問。

唯一出現「技術選型」四個字的地方，是第一天早上 8 點 39 分，開工後第四分鐘。CC 是這樣寫的：

技術選型是 SwiftUI + SwiftData、零第三方套件、零後端。

它在通知我。

而這個我沒參與的決定，後來決定了我四個 App 的一切：隱私標籤全部可以填「不收集資料」、審核備註好寫、沒有伺服器要顧、沒有帳號客服要做。

那唯一一則問原理的，是 7 月 25 日：

我在參加 iPlayground 的開發者活動，學習一點怎麼開發。請問我們有用 Swift Model 嗎？為什麼？

我會問那題，是因為那天我人在開發者活動的現場。

Day 14 我寫過公司技術部門大主管問我「你的 SDK 是用 Vision framework 還是 Foundation framework」，我慌張地回頭去查。那是同一件事的另一次。兩次讓我問出架構問題的都不是 AI，是人。

這是好事也是風險。

好事是我跳過了學習技術的時間，不必懂這些就能做出 4 個 App 來。CC 問我的都是那些產品經理必須下決策的事情，需求啦、排序啦、結果的感受啦等等。

風險是，我也剝奪了自己更深入學習與拓寬需求估算時程與資源的機會。像是用哪種語言開發、延展性、如果要有 API 會花多少時間與要注意的事情、如果要改一種 UI 風格該怎麼做。

我一個也沒辦法回答。我沒有因為做完 4 個 App，變成一個開發小天才。

下結論說 Vibe Coding 學不到東西之前，倒是可以再記錄一次，我摸出什麼流程，踩了什麼坑，還有我還缺什麼。

摸出的流程：原則、引擎模組化、清單

第一天就把產品原則定死，而且不改。 免登入、零後端、絕不刪除、裝置端 AI，再加上零第三方套件。這五條不是理念，是工程上真的會換到東西：隱私問卷好填、審核備註好寫、沒有維運、沒有客服。我後來才想明白，十天能上架四個 App，結構性的原因就在這裡。

第二個之後越做越快，因為引擎可以搬。 《這隻》的場景分類是從《這趟》的旅程偵測改的，中間那層做成平台中立的，Mac 上的命令列工具跟 App 共用同一份。四個 App 從第一行程式碼到上架，分別是 11、8、7 天上下。

最後是開工順序本身變成一份清單。 repo 開在 ~/Projects/，同一天就建好 GitHub 私有遠端並推上去，素材資料夾開在桌面的下載暫存區。

踩到的坑：iCloud 同步、安裝成舊版、更新裝機前沒按掉舊版、年份用民國還是西元

其實踩到的坑很多，但留 4 個比較大的。

iCloud 會蓋掉程式碼。 這條發生了五次，是最貴的一條。我的專案本來放電腦桌面，而桌面在 iCloud 的同步範圍裡。一天之內我遇過：檔案多出一個叫 * 2.swift 的分身、副檔名被吃掉、整個檔案蒸發、刪除動作混進 commit。

規則後來變成程式碼一律放 ~/Projects/，桌面只放截圖跟文件那種丟了還能重做的東西。

建置產物殘留，把三天前的版本裝回我手機。 搬過 repo 之後，電腦上留了兩份建置快取，安裝腳本抓到舊的那份。裝完打開，icon 變回舊的，功能也退回去了。

我看手機看半天，以為自己記錯了。

更新裝機不會關掉正在跑的舊版。 所以我測到的是舊的那個。每次裝完必須先把 App 滑掉再開。Playbook 上寫這是「分享卡張冠李戴事件的真兇」。Day 15 我寫過評語張冠李戴測不出來，那是測試寫不出斷言；這一條更蠢，是我根本沒在測新版。

上班都會記得這題，但自己做又一次做好幾個，有時候就亂了套。

日期不釘死公曆加裝置時區，民國曆的年份會被寫進資料庫。 這條是跑腳本才發現的。它不會閃退，不會報錯，它只是安靜地把髒資料存進使用者的手機。

就像 Day 17 說的：資料是對的，邏輯是對的，結果是錯的。安靜的錯誤。

缺什麼：無障礙、當機回報、效能基準、資料遷移、在地化

Day 19 寫兩個 App 交叉檢驗的時候，我本來很得意自己的英明神武，寫到最後忽然想起問了 CC：以標準開發作業來說，我還少做了什麼？

Day 15 也問過一次類似的問題，那次問的是測試那一層，它回我 UI 測試、整合測試、CI、覆蓋率四項。這次問的是整個交付流程，它洋洋灑灑了 5 項，我回去翻紀錄，五項在當時都是真的空白。

無障礙的動態字級，也就是使用者把系統字體調到最大之後，畫面還能不能看。我做了 iPad 版是因為想給長輩用，而長輩打開 App 的第一件事就是把字調大。調大後會順利還是跑掉？那個畫面我從來沒看過。

當機和錯誤沒有回報路徑。 零後端等於零監控。App 在別人手機上壞掉，我不會知道，對方只能去 App Store 留一顆星。

9 月份有網友留言提醒《這趟》翻照片時候有點卡頓，Xcode 有 Crash 與 Hang 監測，但沒有回報路徑就只能用拼湊的。

效能沒有基準值。 掃 2577 張照片要多久、耗多少電、手機會不會熱到降頻，我只知道「跑得動」。我有跟 AI 討論過跑太久，但沒有把它變成一個每次都要做的監控值，這是我的失職。

資料遷移只有紀律沒有機制。 靠的是「欄位只加不改、預設值寫在宣告上」這種約定。加欄位沒事，改型別或刪欄位，使用者的資料庫就打不開了，而東西在別人手機裡。

在地化是零。 沒有任何一行多語字串。這是選擇不是疏忽，但 ASO 可以在英語世界與日語世界上架，App 只有繁體中文版會浪費這個機會。

前面講到技術選型，零後端是第四分鐘定的，回報路徑這個洞就是那時候一起挖好的。我查了一下市面上給 Vibe Coder 的流程圖，七個步驟裡有一格叫「設定監控」。別人的流程圖上有這一格，我的架構讓它永遠是空的，而這是我自己無知無畏下點頭的。

還有一件事要講清楚。寫這篇的時候我回頭查了程式碼，盤點完的當天我就把四項寫進待辦，真正動工的只有一項：《這趟》補了動態字級，另外三個 App 還是沒有人看過字調大的樣子。

盤出清單跟修完清單，中間差得遠。

心得

我本來想把這篇收在一句話上：我還是不會寫程式，但我多知道了該設哪幾個關卡。

後來想想不對，我當 PM 時候就會，把關卡設計得更細也是我本來就會做的事。設定關卡不是 Vibe Coding 給我的。

Vibe Coding 給我的是主控力，黑盒子還在，但變成透明的。

回答問題與問問題變便宜了，所以我把整條決策鏈抓回自己手上，包括以前會放掉的小岔路。

但是，它沒有給我的，是可能性的視野，那些也是我第一個月決定去 iPlayground 補課、2 個半月後開寫鐵人賽想要學到的東西。

當我答不出後端或 UI 需要的時間與資源與挑戰，不只代表我做不出來，還代表我對那類的需求掌握度不夠高。

需求的天花板，來自我知道的可能性有多高。

所以下一步，不是去學寫程式，是去做一個我現在做不出來的東西，讓它逼我長出新的問題。而且這次，多問一些我還不知道的事情。

那大概就是「然後呢」的答案之一。

這個系列同步寫在我的部落格：yojuhsu.com/blog

前一篇：【Day23】能幹的是 AI，還是我？
下一篇：Day 25，文件整理與推 git